Non repudiation #37
Non repudiation #37
Conversation
Signed-off-by: Jim Zhang <[email protected]>
Signed-off-by: Jim Zhang <[email protected]>
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #37 +/- ##
==========================================
+ Coverage 65.61% 70.44% +4.83%
==========================================
Files 12 12
Lines 538 538
==========================================
+ Hits 353 379 +26
+ Misses 145 112 -33
- Partials 40 47 +7 ☔ View full report in Codecov by Sentry. |
Signed-off-by: Jim Zhang <[email protected]>
Signed-off-by: Jim Zhang <[email protected]>
Co-authored-by: Chengxuan Xing <[email protected]> Signed-off-by: jimthematrix <[email protected]>
Co-authored-by: Chengxuan Xing <[email protected]> Signed-off-by: jimthematrix <[email protected]>
Signed-off-by: Jim Zhang <[email protected]>
| // generate shared secret for the authority | ||
| var sharedSecretAuthority[2]; | ||
| component ecdh2 = Ecdh(); | ||
| ecdh2.privKey <== inputOwnerPrivateKey; |
There was a problem hiding this comment.
I'm not grasping this, we generate a key using the input owner private key to then sign the values passed in so in the future we can check with the public key that the entity that had the private key was the one that tried to perform this transaction?
There was a problem hiding this comment.
my understanding is it's used by ECDH to compute the shared key
There was a problem hiding this comment.
But we also have an input into the circuit of the authority public key
There was a problem hiding this comment.
It's a key pair of the public key provided and the private key of the input owner?
There was a problem hiding this comment.
the shared secret is used to encrypt rather than sign, the goal is so that the receiver of the encrypted values (the one whose public key is used here) can use their private key and the sender's public key, to derive the same shared secret (this is per the Diffie-Hellman key agreement protocol) to decrypt
There was a problem hiding this comment.
Got it now!
- The inputs are signed by a shared key of the initiator so their private key and the public key of the regulator so only the regulator can in the future decipher them
- The regulator can then verify that the cipher matches all the other inputs into the circuit by decrypting with a shared key of the regulator private key and the initiator public key!
Awesome
There was a problem hiding this comment.
we also have an input into the circuit of the authority public key
yes that's the right observation. we are performing two separate encryptions, targeted for two identities (the receiver of the output UTXO, as well as the authority). so we use two separate ECDH to deriver two separate shared secrets to do the encryption
Add a new circuit that adds encryption with a published authority key of all the secret values of a transaction. This allows the smart contract to enforce non-repudiation with the ZKP, while allowing the authority (which possesses all the secret values of all transactions) to be the arbitrator in disputes.